      ********    **************************************************
             *    *                                                  *
            *     *                 The independent guide to BITNET  *
           *      *                                                  *
          *       *                                   January, 1989  *
         *        *                                                  *
        *         *                          Volume 3, Number 6 - 7  *
       ********   *                                                  *
                  *                                                  *
        ***       *                                                  *
       * * *      *                                                  *
       * * *      *                                                  *
       * * *      *                                         **********
       * **       *                 **********             ***********
                  *                 **********             ***********
           *      *                 **********             ***********
           *      *                 **********         ***************
       ******     *                 **********            ************
           *      *                 **********          ******  ******
           *      *                  ********           **********  **
                  *                    ****              *************
       ********   *                     **                 ***********
             *    *                     **         *******************
            *     *                    *******************************
           *      *                   ****************************  **
            *     *                   ********************************
             *    *                    ***************************  **
       ********   *                     **       *********************
                  *                     **         ***************  **
        ***       *                     **           *****************
       *   *      *                     **      ******************  **
       *   *      *                     **   *************************
       *   *      *                     **  **********************  **
        ***       *                     ** ***************************
                  *                     ** ***********************  **
       ******     *                     ** ***************************
           *      *                     **  **************************
           *      ********              **   *************************
           *      *****************   ********************************
       ****       ****************************************************
                  ****************************************************
           *      ****************************************************
           *      ****************************************************
       ******     ****************************************************
           *      ****************************************************
           *      ****************************************************
                  ****************************************************
       ********   ****************************************************
           *      ****************************************************
           *      ****************************************************
           *      ****************************************************
       ****        **************************************************

1

       *     *  ****** ******* *     *  *****  *     * ******* *     *
       **    * *          *    **   ** *     * **    *    *    *     *
       * *   * *          *    * * * * *     * * *   *    *    *     *
       *  *  * *****      *    *  *  * *     * *  *  *    *    *******
       *   * * *          *    *     * *     * *   * *    *    *     *
       *    ** *          *    *     * *     * *    **    *    *     *
       *     *  ******    *    *     *  *****  *     *    *    *     *
       *                       *     *                               *
        ***********************       *******************************


       Christopher Condon    Editor                   CONDON @ YALEVM
       Timothy Stephen       Associate Editor        STEPHEN @ RPICICGE
       Craig White           Associate Editor         CWHITE @ UA1VM
       June Genis            Contributing Editor      GA.JRG @ STANFORD
       David Hibler          Contributing Editor    ENGL0333 @ UNLVM
       Henry Mensch          Contributing Editor       HENRY @ MITVMA
       Deba Patnaik          Contributing Editor        DEBA @ UMDC
       Gerry Santoro         Contributing Editor         GMS @ PSUVM
       Marc Shannon          Helpdesk Editor        HELPDESK @ DRYCAS
       Glen Overby           Technical Assistant    NCOVERBY @ NDSUVAX
       Gary Moss             Point of View              MOSS @ YALEVM


       ********************* Contents - Issue 28 *********************

        *********
       *     *** *  EDITORIAL PAGE____________________________________
       *    ***  *
       *  ***    *  Bitnotes ....................................... 1
       ***     ***  The Human Factor ............................... 4
       *    ***  *  Flames To: ..................................... 8
       *  ***    *  The Way BITNET Moves .......................... 10
       * ***     *
        *********

        *********
       * ***     *  FEATURES__________________________________________
       * ***     *
       * ****    *  JBH Online .................................... 13
       * *****   *  Announcing CHESERVE ........................... 14
       * ******  *
       * *** *** *
       * ***  ****
        *********

        *********
       *         *  DEPARTMENTS_______________________________________
       *     *****
       *    ***  *  Headlines ..................................... 15
       *   ***   *  New Mailing Lists ............................. 17
       *  ***    *  Feedback ...................................... 19
       *****     *  NetMonth Policies ............................. 20
       *         *
        *********

      *********************** Distribution: 3622 *********************
1

                                                                Page 1


        *********
       *     *** *  Bitnotes
       *    ***  *
       *  ***    *  by Christopher Condon
       ***     ***
       *    ***  *  Yale University
       *  ***    *
       * ***     *  CONDON@YALEVM
        *********


                         "Terminology of the Damned"


       The tall  man in the italian  suit steps into the  brightly lit
       television studio.    He smiles,  hiding  his upper lip  with a
       dark,  bushy moustache.   The reflected glare from his teeth is
       blinding,  if only for  a moment.   He is at ease  here,  he is
       comfortable here.  This is his environment.

       His three companions on the stage are not so fortunate.   While
       they are  obviously somewhat  smarter than  Him,  they  are not
       nearly so polished,  so confident.   Especially not here,  with
       millions of people watching.

       Well, they are only taping now,  but people WILL be watching...
       They  wonder  why they  have  come  to  this.    A day  in  the
       spotlight?  A MENSA membership?  Money?

       Our host's smile fades slightly, imperceptibly as he glances at
       the cards in his hand.   One of the contestants speaks,  and it
       begins...

       "I'll take BITNET SERVERS for five hundred."

       He smiles and  reads the answer.   "People access  this kind of
       server when they are looking for someone--"

       A bell rings.

       "What is a list server?"

       He frowns at  the contestant.   "In some cases,   yes,  but not
       quite what we wanted.  I'll  finish the answer.   People access
       this kind of server when they are looking for someone's network
       address."

       A brief  pause and a  bell sounds again.    Another contestant:
       "What is a name server?"
1

                                                                Page 2


       Out host  glances at  the judges  and they  shake their  heads.
       "I'm sorry," he says.  The contestant looks very confused.

       A buzzer sounds, and he explains.  "The terminology was changed
       recently and the term *name server* is no longer accurate.  The
       correct response would have been *user directory server*..."

       *****

       Computing, like many disciplines, has it's own language.   Like
       any  language   it  has  its   own  dialects,    accents,   and
       characteristic  inflections.    This  is   especially  true  of
       computing, where the technology moves so quickly that new words
       are invented  every day so  we can  avoid using new  terms like
       "that new thigamajig from Apple."  If anything,  we can confuse
       the people who were starting to understand what we were saying.

       BITNET has it's own dialect in  the language of computing.   We
       have terms like "file server" and "list server" and "electronic
       magazine."  While these terms are often  used in other areas of
       computing, here they have a different (if subtly so) meaning.

       I  don't know  if  anyone is  sure from  where  the term  "name
       server" came.   It  is one of those little pieces  of our young
       culture that  no one  bothered to  document.   Certainly  it is
       accepted, or else no one would understand what significance the
       names NAMESERV@UNCAMULT and NAMESERV@DREW have.

       Alas, the Internet has grown up with a very similar term of its
       own, the "name service".   Unfortunately,  this type of service
       does something  totally different  than the  "name servers"  to
       which we are used.  As a matter of fact, they have been reading
       the  literature that  comes  out of  BITNET,   confused by  the
       similarity between the  terms,  and thinking us  complete boobs
       for saying that a "name service" does THIS, when we were really
       talking about "name servers" all along.

       Makes sense?  Of course not...

       Now,  the Internet  term "name service" has  little relation to
       the function it performs.   However, it has been suggested that
       this  confusing Internet/BITNET  terminology  situation is  the
       perfect opportunity to  replace "name server" with  something a
       little  more descriptive.    Hence the  phrase "user  directory
       server."  It doesn't exactly roll off the tounge,  but I didn't
       make it  up,  so  don't blame  me.   It  appears now  in BITNET
       USERHELP and BITNET SERVERS (as well  as the BITLIB online help
       product).
1

                                                                Page 3


       Come to think of it, "list server" is a little vague,  too.   I
       mean,  it could be a list  of anything.   Perhaps "mailing list
       server" would be more sensible, or "the Eric Thomas All-Purpose
       Server", or...

                   Virtually,

                         Chris Condon@YALEVM

1

                                                                Page 4



        *********
       *     *** *  The Human Factor
       *    ***  *
       *  ***    *  by T. D. Stephen
       ***     ***
       *    ***  *  Rensselaer Polytechnic Institute
       *  ***    *
       * ***     *  STEPHEN@RPICICGE
        *********


       The pace  of technological change being  as dizzying as  it is,
       most computer users, however reluctantly, have grown accustomed
       to  watching their  applications and  hardware become  obsolete
       overnight.   The  thirty five hundred dollar  IBM-PC compatible
       that I  sweated out of  my department in  1985 lost 70%  of its
       resale value and was technologically passe  a year after I took
       it out of the box.   Similarly,  the technology used to provide
       BITNET is  already outmoded and has  been outmoded for  quite a
       long time.    Much better  wide-area networking  protocols than
       BITNET's -- protocols that provide dynamic routing of messages,
       wider bandwidths  and faster  transmission between  machines --
       have been  in existence for  some years.   BITNET  continues to
       rely  on its  present technology  for  the same  reason that  I
       continue to rely on my outdated office PC:  keeping up with the
       state of the art  is expensive and if what is  already in place
       continues to provide  a minimally acceptable level  of service,
       it's all the more difficult to justify the cost of upgrading.

       Nevertheless,  it is worth considering what a future,  upgraded
       BITNET might offer.  Articles appearing during the past year in
       the EDUCOM Bulletin and the  Chronicle of Higher Education have
       provided a  glimpse.   Imagine  a network  uniting researchers,
       educational  users  from  every level  (primary  and  secondary
       schools,    community   colleges,    four-year   and   graduate
       institutions),    corporate  centers,    government   agencies,
       libraries, publishers, supercomputer centers,  and professional
       associations.

       Like today's  BITNET,  this  BITNET of  tomorrow would  provide
       electronic mail and file transmission;  however, it would do so
       differently.   One of the more  noticeable differences would be
       the type of terminal that you might use to connect up.  Imagine
       a mouse-driven desktop workstation with a large (17 inch or so)
       high-resolution screen.   The operating system for this machine
       provides a  Macintosh-style graphic-oriented user  interface to
       network functions (pull down  menus,  icons,  layered windows).
       If you've  been following  the press  descriptions of  the NeXT
       computer, picture one of those.
1

                                                                Page 5


       To use  a network  resource like  Comserve,  the  user opens  a
       window on a directory of network  services,  moves a pointer to
       the entry  for Comserve and  taps a  button.   A second  or two
       later,  a  window opens  to a  terminal session  with Comserve.
       Although mail,  files  and messages will still  be sent between
       individuals,   the primary  mode  of  interaction with  network
       servers will be through directly established terminal sessions.
       No more commands sent in mail messages, no more one-line "tell"
       messages hopping from node to node; dynamic routing, high speed
       links and wide bandwidth mean that it will be practical to have
       a terminal session with a server in the same sense that one has
       a terminal session on one's university mainframe.  In this way,
       the  net  will function  more  in  the  fashion of  today's  PC
       bulletin boards where users directly  operate a program running
       on a remote machine.

       Getting a file  from a server would be more  convenient and far
       faster than current methods: point to the file's name in a list
       displayed in a sub-window by the  server,  tap a button and the
       server  transfers  a copy  of  the  file to  your  workstation.
       According  to estimates,   transmission  speeds  of 10  to  100
       million  bits   per  second  are  possible   (BITNET's  present
       transmission  speed is  9,600  bytes  per second  between  most
       nodes)  with the potential for speeds  to reach far higher,  so
       there would be  no appreciable delays.   Transmission  would be
       from point  to point,  as it  is in the Internet  FTP procedure
       today.   This means  no more waiting days  for poorly monitored
       intermediate computers to  come back on line  and transmit your
       messages, no more waiting days or weeks for large files to make
       it through clogged queues; in fact, no more queues!

       The  range of  network  services available  to  users would  be
       expanded  considerably.    Library  materials   --  papers  and
       journals certainly --  would be available from  library servers
       located   at  various   points  on   the  net.     Professional
       associations and other organizations  would provide services to
       users  over  the  net.    The  availability  of  Internet-style
       "Telnet" sessions  (i.e.,  using the  network as a  vehicle for
       establishing a session  on a remote computer)   would allow new
       dimensions in  cooperative scholarship:  imagine being  able to
       collaborate with  co-authors at distant  sites by working  on a
       draft of a document simultaneously.

       Ira Fuchs,  Erich Bloch and others have described some of these
       potentials in the  Summer/Fall 1988 issue of  EDUCOM's Bulletin
       and  I  encourage  individuals  interested  in  the  future  of
       academic networking  to take  a look at  this set  of articles.
       The  potential  of  the  national   network  they  describe  is
       tremendous  in  its  implications   for  enhancing  educational
       excellence  and for  improving  the  quality of  new  knowledge
1

                                                                Page 6


       produced within research centers.  The major stumbling block of
       course  is  money.    The  cost  of  such  a  network  will  be
       staggering.   According to a recent wire service item,  Senator
       Albert  Gore introduced  legislation  last  October that  would
       create a 400 million dollar fund to cover a portion of this net
       -- presumably  the backbone.    Four hundred  million is  not a
       great deal  of money,   but keep in  mind that  this is  only a
       rather small part of the total cost.   Consider that NeXT-style
       workstations will  be at least five  times as expensive  as the
       terminals or  PCs most  of us  use to  communicate over  BITNET
       today.    Since many  university  departments cannot  presently
       afford to provide professors with  simple ASCII terminals,  the
       cost  of computing  hardware will  need  to fall  substantially
       before many  will be  able to  participate fully  in tomorrow's
       network.

       While  legislators deliberate  and  we wait  for  the costs  of
       workstations to come down,  we should  be doing whatever we can
       to educate  university,  public and government  officials about
       the potential such  a network can provide.   It is  going to be
       difficult  to sell  the network  using  the standard  arguments
       about how  it will increase  productivity or  sharpen America's
       competitive edge in world  markets.   Unsubstantiated claims of
       this  sort were  shoveled  at the  public  by manufacturers  of
       personal computers during the early portion of this decade and,
       having weathered that barrage,  many  Americans have lost their
       innocence.     Furthermore,     many   would    rank   BITNET's
       interconnection with international networks (JANET, EARN, etc.)
       as one  of its greatest  values,  so  it could be  difficult to
       explain how a network that allows researchers and scholars from
       other countries to  participate is going to create  an edge for
       the  US.   Joining  these hurdles  is  the credibility  problem
       created by the recent media circus over network viruses.   In a
       focus segment, the McNeil/Lehrer Newshour depicted Arpanet as a
       vulnerable network  jockeyed by a  group of  exuberant Stanford
       undergrads who appeared to sustain themselves solely on lockers
       of candy bars.

       Clearly,  however,   a strong base  of grass roots  support can
       help.   We  need to let  legislators and  campus administrators
       know that we want them to  get behind academic networking.   In
       particular,  we need to extend campus involvement in networking
       as widely  as possible.   Those  who haven't used  networks are
       usually  impressed once  they've seen  things work  and have  a
       sense  of  the  possibilities.    Each  newcomer  represents  a
       potential  network   advocate  (obversely,   each   student  or
       professor who  is denied access  represents a  lost opportunity
       for  support),   so   it  is  to  our   advantage  to  increase
       participation in networking throughout the academy.
1

                                                                Page 7


       Based on our experience with Comserve, I think that there is no
       question  but  that  disciplinary   services  can  function  as
       significant  magnets  for  involving  new  people  in  academic
       networking.   In fact, I invite anyone who has any doubts about
       the promise of  networking to take a look at  what has happened
       with Comserve over the past two and a half years.   Comserve is
       a  service that  provides educational  and research  materials,
       information about graduate programs,  course syllabi and so on.
       It  provides a  method for  users to  search for  bibliographic
       references and it provides a 'white pages' of network addresses
       of  students and  professionals  in  the communication  studies
       discipline.   In  addition,  users  can subscribe  to about  20
       online   conferences   covering  divisions   of   communication
       scholarship.

       Comserve processed  its 100,000th command  around the  first of
       the year and  is now managing 3,000 subscriptions  to its suite
       of conferences.    It has been used  by people from  over 6,200
       network  addresses  who  represent 19  countries  and  5  other
       networks and  it gains approximately  100 new users  each week.
       Now if Comserve was a system that dispensed nude photographs, I
       wouldn't find these figures surprising.   However,  Comserve is
       an academically oriented service and,   as such,  delivers some
       relatively  dry   material.    Nevertheless,    this  type   of
       disciplinary  resource  has  proven  sufficiently  valuable  to
       attract quite a  number of professors and students  to the net,
       and  these   users  hail   from  a   social  science/humanities
       discipline that is far from the forefront of computer literacy.
       Clearly,  one way to increase  grass roots support for academic
       networking would be to set up services similar to Comserve that
       cater to other academic disciplines.

       Today's  BITNET was  built from  the voluntary  labors of  many
       people and their efforts deserve  our gratitude.   Now there is
       an  opportunity for  each  of us  to  contribute to  tomorrow's
       BITNET.   If this visionary network is to become a reality,  we
       need to  get behind  Fuchs,  Bloch and  the others  and promote
       academic networking  to our legislative representatives  and to
       our campus  administrators.   Those in  BITNET's administration
       could  do  much  to  forward the  effort  by  helping  academic
       disciplines create and sustain services similar to Comserve.
1

                                                                Page 8


        *********
       *     *** *  Flames To:
       *    ***  *
       *  ***    *  by Craig White
       ***     ***
       *    ***  *  University of Alabama
       *  ***    *
       * ***     *  CHWITE@UA1VM
        *********


       Hello all,

       I hope everyone's holidays were good and that this year will be
       your best ever.   It seems ironic that the season of good cheer
       can be so trying because of  unattended computers and the like.
       A couple  of times  this month I  have anxiously  awaited files
       that took so  long to arrive.   I have received  many pieces of
       mail regarding the Shapiro book.   Several people wrote to tell
       me how the book  could be ordered.   So for all  of you who are
       interested,  I gratefully pass on  the following from Michel S.
       Perdreau who  is a  librarian at  the Southern  Campus of  Ohio
       university.   "It may (?)   still  be available from Rand Corp.
       1700 Main Street, P.O.  Box 2138, Santa Monica,  CA 90406-2138,
       for $4.00  (US).   It  is also  available as  an ERIC  document
       (ED2690033) from most university libraries."

       This months  flame is not  really a  flame.   It is  a question
       that,  judging  from my  mail,  seems to  be important  to many
       people.   The question is this:   "How do I go about retrieving
       files from the trickle servers of the SIMTEL20 archives?"

       First off let  me explain what these trickle  servers are.   On
       the Internet there is a machine, SIMTEL20.   The administrators
       of this machine have seen fit to provide several directories of
       public domain software,  mainly of the IBM PC varieties but not
       exclusively.   This  software is  available via  ANONYMOUS FTP.
       For those  of you  who are unfamiliar  with FTP  (File Transfer
       Protocol),  it  is a method  of transferring files  between two
       hosts.    It is  the primary  way to  move data  around on  the
       Internet.   Because  FTP works  in a  disk to  disk fashion  as
       opposed to SENDFILE which stores files in your reader, you must
       have a userid to log into the system you want to transfer files
       from.  This is where the anonymous part comes in.  ANONYMOUS is
       a  special  userid that  anyone  can  use  for the  purpose  of
       transferring files.

       Because  most  BITNET hosts  do  not  have  FTP access  to  the
       Internet, the trickle servers were invented.   When you request
       a file,  if the server that you  are dealing with has the file,
1

                                                                Page 9


       it sends it to you.   If it does not have the file, it requests
       it from the next server up.   Each time a server gets a file it
       keeps a copy for the next person who may ask for it.   This way
       requested files "trickle" down to the servers with each request
       going only as far up the chain of servers as is needed.

       In  my opinion  this is  a very  efficient way  for servers  to
       operate.   It keeps  network traffic down and  allows server to
       evolve depending upon what files the users in a particular area
       are interested in.   In addition, the servers keep track of how
       much  they send  to each  node and  there are  limits on  this.
       Unfortunately,  this can  create a problem.   The  problem that
       many people  are encountering is  that when  they try to  get a
       file they are  informed that the limit for their  node has been
       exceeded for that day and that they should try the next day.  I
       have talked with  people who say that they  ordered files right
       after midnight and got the message then too.   I have been told
       of a similar situation that occurs with LISTSERVs that retrieve
       files from SIMTEL20.   It probably has something to do with the
       different time zones.

       There  is a  slightly  different twist  on  this scenario  with
       LISTSERVs.   You order a package of  programs and at some point
       during the retrieval  of the package you are  informed that you
       have  execed the  limits for  the day  and you  must try  again
       tomorrow.   Many times  it's very difficult to  figure out what
       files  have  and  haven't  been shipped.    This  can  make  it
       extremely frustrating for users to  get the software they want,
       and in the case of new networkers,  leaves them with a negative
       impression of networks.  Many people who have taken the time to
       write to me  about this are genuinely upset and  have things to
       say like  "What good  is a network  if you  can't get  what you
       need?" and  other such  statements often  accompanied by  crude
       expletives.

       Winding down,  I think that the problems caused by this feature
       of servers are serious,  but with  network congestion as it is,
       it seems to be effective in reducing network traffic.   I would
       like  some feedback  on this  problem  and I  will continue  to
       follow this for all of us.   Meanwhile,   I hope you will get a
       copy of  the Shapiro book  and read.    This is what  it's card
       catalog entry looks like here:

            Author: Shapiro, Norman Zalmon, 1932-
             Title: Toward an ethics and etiquette for electronic mail
                    Norman Z. Shapiro, Robert H. Anderson.
       Publication: Santa Monica, CA : Rand, 1985
          Material: vii, 35 p. ; 23 cm.

       As  always  send  your  questions,    comments  and  flames  to
       CWHITE@UA1VM.
1

                                                               Page 10


        *********
       *     *** *  The Way BITNET Moves
       *    ***  *
       *  ***    *  by Eric Thomas
       ***     ***
       *    ***  *  Centre Europeen de la Recherche Nucleaire
       *  ***    *
       * ***     *  ERIC@LEPICS
        *********


       * Note:    This editorial  was extracted  with permission  from
       correspondence between  the author and  the Editor.   It  is in
       response to the Bitnotes column  appearing in the November 1988
       NetMonth.

       Funny that I got the issue  of Netmonth where you're mentioning
       user directory standardization right after  I finished the test
       of the first version of the LISTSERV UDD...

       Anyway,  I take your point about  the disorganized way in which
       changes are made  to BITNET.   I would fully agree  with you if
       BITNET were a corporate or  self-supporting network.   But it's
       not, and I therefore have to disagree.

       The  discussion groups  you are  mentioning  are,  quite  often
       (albeit not  always)  nothing  but a group  of people  who have
       self-appointed  themselves as  being  responsible for  Deciding
       what "The Way to " is.   I would
       have nothing against this, if it were useful.   But apparently,
       it's not.

       I remember subscribing to some of these groups, 3 years ago.  I
       heard discussions about  whether X should be done the  A way or
       the B way,  knowing that there were advantages and drawbacks to
       both A and  B.   After some time I thought  that,  although the
       actual discussions were boring, it might be interesting to come
       back in 6 months and see what has been decided.   I signed off,
       came  back maybe  one  year later,   and  they were  discussing
       whether X should not,  after all,  be done the C way.   At this
       point I completely lost interest in these discussions.

       The most irritating part is that, when they eventually do reach
       some  decision,   they  all quickly  withdraw  when  the  Fatal
       Questions is asked: "Ok, now who will write the software"? They
       are all so busy that they  cannot contribute a single minute of
       their time to the actual code, even though they apparently have
       no problem  finding time to send  100-lines notes every  day on
       the subject.
1

                                                               Page 11


       Now,  on the other side,  you  have the developers.   They have
       often been described  as having an arrogant (should  I say IBM-
       like?)  attitude,   ie "this is the  way I decided it  would be
       done, take it or leave it, complaints will be discarded as they
       are received".   That is a cheap shot.   Quite to the contrary,
       most developers  are eager to  receive input from  users and/or
       system managers who  would like to see this new  feature in the
       code or would like that to be done in another way.   Whether or
       not they will actually do what  these people suggest is another
       matter -  after all,   they're not  a netwide  free consultancy
       office where you  can mail your requests and  get the resulting
       code 2 weeks  later.   The reason why  developers usually don't
       participate in the Big Forums is  that they consider this to be
       a waste of time.  Although there is a tiny fraction of "useful"
       people in there, most of them spend their time arguing over the
       sex of angels, and, indeed,  every 20 notes or so there comes a
       message from someone saying "You are  on the wrong track,  this
       is completely stupid, the way to go is (...)".   Then 10 heated
       replies to the message, and so on.

       It is then very easy to say that the developers didn't heed the
       advice of the Forums.   They have, at least,  provided software
       that exists, and usually even works :-) If it meets only 75% of
       the  needs  of  the  BITNET  community,   it's  already  a  big
       achievement - my  experience has shown that  it's impossible to
       satisfy  more than  80-90%  of people  with  a  given piece  of
       software.    Look at  the  popular  pieces of  hardware  and/or
       software on the marketplace,  and you'll have to agree with me.
       MACs and UNIX seem  to become the norm,  yet I  can easily find
       some 10% of people who strongly dislike it.  XEDIT is deemed to
       be a very good editor, and still some people can't stand it.

       Chris:    "I  agree  that  BITNET  and  EARN  aren't  corporate
       networks.   However, most users are unaware that services which
       seem pretty basic (LISTSERV, RELAY) are provided by volunteers.
       Their  membership fees  are paying  for the  ability to  access
       these services,  not  the services themselves,  and  they don't
       know it!"

       Now, I don't know about NetNorth,  but EARN has an organization
       similar to BITNET where you pay a  membership fee and hook up a
       line and you get the service.    However,  it is true that with
       this  amount of  money,   you can't  expect  the  service of  a
       corporate network.  BITNET has a NIC and EARN doesn't.

       Anyway, EARN and BITNET,  and probably NetNorth,  are in a very
       similar situation.   Users don't know what comes from what they
       pay and what is an extra,  and in fact they don't even know how
       much has  been paid to join  the network.   They  will complain
       anytime they  feel the  service does  not meet  their standard;
       sometimes they'll be right, and sometimes they'll be wrong.
1

                                                               Page 12


       The EARN Board of Directors, and probably also the BITNET Board
       of Trustees,  consciously or unconsciously  attempt to fool the
       users into believing that all these  extras come from the money
       they're giving,  i.e  are supported (if not  sponsored)  by the
       network organization.   This makes it  much easier for users to
       "swallow the pill";  indeed, a lot of people might get upset if
       they knew all that they are paying for is, er, well, that is, a
       legal  framework within  which  much of  the  work  is done  by
       volunteers.   A very good example is a Nordunet network manager
       who recently told  me:  "the basic services  of EARN/BITNET are
       electronic mail,   MAIL/MAILBOOK/MAILER,  LISTSERV,  and  a few
       other minor services".

       Of course,  the BoD is smart enough never to say anything about
       having sponsored the the  development of the volunteer-supplied
       utilities in writing,  or in any way that might be construed as
       implying they might have to actually finance any of this.  But,
       if you had been  "invited" to be a member of  the EARN panel in
       the EARN'88 user meeting in Turkey,   you would have seen up to
       what point  EARN is  advertising these  services (and  probably
       rightfully so).  You would also have been astounded by how they
       are  able to  make  it  *sound* like  it  all  came from  EARN-
       promoted,    EARN-organized,   EARN-fostered,    EARN-monitored
       development  while  at  the same  time  pronouncing  the  words
       "developed by Eric  Thomas,  to whom I would like  to extend my
       thanks on behalf of the whole EARN User Community."

       Now, if you cross the fence and look at it from their way, it's
       quite simple.  Users (the people who supply the money and trust
       that give you the power you have) ask you, "how can I do that"?
       Well,  you have  no EARN/BITNET-funded way of  doing that,  you
       have no vendor-supported way of doing it,  but you have a long-
       haired guy  down there in  Tennessee who's done  something very
       much akin to what  the user is asking for.   If  you say,  "you
       can't",  you stand  the chance of disappointing  the user,  and
       then actually displeasing it when he finds out by himself.   If
       you say, "there is this thing, but it's completely unofficial -
       use at  your own  risk",  the user  will invariably  reply "Why
       isn't it a standard tool,  or  why doesn't EARN make one",  and
       you will have disappointed him once more.  If you say, "there's
       this LISTSERV software  that will do exactly what  you want and
       was developed in EARN" (which  is,  stricto sensu,  an accurate
       statement),  you will imply that this  is part of the "package"
       and the user will be happy.   Until  he finds out.   If he ever
       does...
1

                                                               Page 13


        *********
       * ***     *  JBH Online
       * ***     *
       * ****    *  by John B. Harlan
       * *****   *
       * ******  *  University of Notre Dame
       * *** *** *
       * ***  ****  ONLINE@IRISHMVS
        *********


       "EXECUTIONS   CITED:    A   new   report   issued  by   Amnesty
       International cites  increasing human rights violations  by the
       Government of the Islamic Republic of Iran since the end of its
       war with  Iraq.   The  abuses include  at least  300 documented
       instances  of secret  executions,  which  AI officials  believe
       represent only the  *tip of the iceberg*.    The executions are
       believed to be  a symptom of the continuing  power struggle for
       eventual   succession   to   the   Ayatollah   Khomeini,    now
       approximately 87 years old..."

       English language news broadcasts  from overseas,  monitored via
       shortwave radio  in South  Bend,  Indiana,   are accessible  in
       digest form to all interested  parties through electronic mail.
       The digest,  JBH Online,  is  produced weekday mornings by John
       Harlan.  JBH Online is distributed free of charge to recipients
       at  academic institutions  nationally  and internationally  via
       BITNET.

       The British  Broadcasting Corporation,  Radio Moscow  and Radio
       Nederland are the three services  John monitors most regularly.
       Others monitored less frequently include Radio Australia, Radio
       Beijing, Radio Canada,  Radio Havana,  Radio Prague,  and Radio
       Tirana.   A number of factors, including atmospheric conditions
       and nearby electrical activity, influence which services can be
       monitored on any given day.   More mundane variables, including
       "line noise" interference in telephone  access to the mainframe
       at IrishMVS (the University of Notre Dame) and John's schedule,
       also determine whether JBH Online appears.

       Begun on  a test  basis in  November 1987  and produced  fairly
       regularly  since  last  spring,  JBH  Online  also  includes  a
       selective capsule  listing of contents  from the  morning's New
       York  Times  and  specialized news  items  gleaned  from  other
       sources,   including journals  and subject-specific  electronic
       mail discussion groups.   In  addition,  occasional specialized
       supplements carry commentary,   interviews,  reading summaries,
       and surveys of JBH Online readers on various topics.

       For  more  information,  or  to  be  added  to the  JBH  Online
       distribution list, send mail to ONLINE@IRISHMVS.
1

                                                               Page 14


        *********
       * ***     *  Announcing CHESERVE
       * ***     *
       * ****    *  by Dan Jacobs
       * *****   *
       * ******  *  University of Maryland
       * *** *** *
       * ***  ****  DAN@UMDC
        *********


       CHESERVE@UMDC is a network file server dedicated to information
       concerning the Chesapeake Bay.   Currently,   the server has on
       disk  back  issues  of  CHESNET  bulletins,   Marine  Notes  (a
       publication of  Maryland Sea  Grant),  It  is the  companion to
       CHESNET@UMDC, an electonic bulletin board.   In the future, the
       server  will  also  have  on  disk  descriptions  of  important
       environmental data sets,  copies of  Maryland Sea Grant managed
       data and and software,  lists of  experts in the many different
       aspects of the Chesapeake Bay, and other information.

       You can send commands to CHESERVE via mail or message, although
       commands sent by mail must be put on the "Subject:" line of the
       note.  The valid commands are:

       HELP - a help file explaining CHESERVE commands will be sent.

       LIST - a catalog of all  files that are available from CHESERVE
       will be sent to you.

       JOBS - a list of current  job announcements that have been sent
       to CHESNET and stored in the file CHESBAY JOBS on CHESERVE will
       be sent.

       SEND fileid  - to request  a CHESERVE file  to be sent  to you.
       For example, if you want vol.  6,  issue 6 of Marine Notes then
       the fileid is MARINE NOTES66.

       WHATIS NEW - a  list of files that have been  recently added or
       updated and available from CHESERVE will be sent.

       If you have  questions,  comments or suggestions,   please send
       them to:

            Dave Swartz  (SWARTZ@UMDC)
            Dan  Jacobs  (DAN@UMDC)
1

                                                               Page 15


        *********
       *         *  Headlines
       *     *****
       *    ***  *  edited by Christopher Condon
       *   ***   *
       *  ***    *  Yale University
       *****     *
       *         *  Send your bits of news to BITLIB@YALEVM
        *********


       * From Jim Conklin:   The  Winter 1989 BITNET Technical Meeting
       will  be hosted  by  University  of Southern  California,   Los
       Angeles on Saturday, February 25,  1989 from 8:30 AM to 6:00 PM
       (PST).

       Objective:   To provide  a  forum for  BITNET  users to  become
       involved with  network-related issues and to  develop proposals
       for  submission  to  the  BITNET Board  of  Trustees,   or  its
       Committees.

       Structure:  After  sign-in and  refreshments the  meeting opens
       with a  one-hour plenary at 9:00.    Then three or  four groups
       (depending on the  forthcoming agenda)  will break  off for the
       rest  of  the  morning.   After  lunch  the  groups  reconvene,
       allowing time for a summary and wrap-up later in the afternoon.

       There is NO FEE to register, meals and transportation are up to
       you.

       If you can attend the meeting PLEASE acknowledge by subscribing
       to  the  BITTECH  mailing  list  by  sending  this  command  to
       LISTSERV@BITNIC  by   mail  or  message:     SUBSCRIBE  BITTECH
       Your_full_name.

       After  joining the  BITTECH  list we  urge you  to  use it  for
       talking amongst  your peers  on meeting  issues --  anything is
       fair game, from the agenda items (both before and after they're
       unveiled)  to carpool and hotel  arrangements.   We will use it
       for official announcements pertaining to the BITTECH meeting.

       * Two more TRICKLE PC software  file servers have been added in
       Europe.   These  are TRICKLE@AWIWUW11  (Wirtschaftsuniversitaet
       Wien)  and TRICKLE@DB0FUB11 (FU Berlin Institut fuer angewandte
       Statistik).   For more information send either server the /HELP
       command.

       * The  VM-UTIL library  of VM  software is  now available  from
       several LISTSERVs.  These include the ones at UTARLVM1, MARIST,
       DEARN, TECMTYVM (a short version), UBVM, and UCF1VM.   The list
1

                                                               Page 16


       of these files can be obtained  by sending one of these servers
       the command INDEX VM-UTIL. Thanks to John F. Chandler and David
       Young for  this update.   Anyone  with questions or  wishing to
       contribute   to   the   FILELIST  may   contact   David   Young
       (DYOUNG@TRINITY).

       * From  Patricia Noeth:   The Annual  BITNET Meeting is  now in
       progress.  Martin B. Solomon, Election Trustee, has sent voting
       packets online and via postal  mail to all BITNET Institutional
       Representatives of Class A and Class B Members.  Currently, two
       items require a  vote:   Election of Trustees  and BITNET/CSNET
       Merger.   Votes must be returned to ELECTION@BITNIC by February
       6, 1989.
1

                                                               Page 17


        *********
       *         *  New Mailing Lists
       *     *****
       *    ***  *  edited by Christopher Condon
       *   ***   *
       *  ***    *  Yale University
       *****     *
       *         *  Send new list descriptions to NEW-LIST@NDSUVM1
        *********


       NEW-LIST@NDSUVM1

       The "NEW-LIST" list  has been established as  a central address
       to  post  announcements  of  new  public  mailing  lists.    In
       addition,  "NEW-LIST"  might be  used as  a final  verification
       before establishing a list (to check  for existing lists on the
       same topic, etc.).   However,  be sure to check sources such as
       the Internet  List-of-Lists (SIGLIST or  INTEREST-GROUPS list),
       LISTSERV GROUPS,   Usenet News newusers  lists,  and  the LISTS
       database on the major LISTSERVs.   Postings to NEW-LIST will be
       regularly published in NetMonth magazine.

       You may subscribe to the NEW-LIST list by sending the following
       command to LISTSERV@NDSUVM1 via mail or message:   SUB NEW-LIST
       Your_full_name.

       Coordinator:  Marty Hoag


       DISARM-L@ALBNYVM1
       DISARM-D@ALBNYVM1

       This is an international and East-West discussion group dealing
       with   all  ways   to   facilitate   disarmament  of   nuclear,
       conventional, chemical and biological weapons.   Topics covered
       include strategic, political, social, educational, psycholgical
       and military strategies. Also, improved relations with USSR and
       China  and   developing  free  telecommunications   with  those
       countries,     education  of   the  public   in  the   economic
       consequences  of continued  arms race,   and  writing of  joint
       position papers on vital topics will be discussed.

       To receive the  monthly digest,  send the  following command to
       LISTSERV@ALBNYVM1   via  mail   or   message:    SUB   DISARM-D
       Your_full_name.   To  participate in  the forum,   subscribe to
       DISARM-L.

       Owner:  Donald F. Parsons MD, PhD
1

                                                               Page 18


       CCMEDH-L@TAMVM1

       CCMEDH-L is a list dealing with the issues associated to cross-
       cultural  medicine  and/or  folk/herbal   medicine.    You  may
       subscribe to the CCMED-L list  by sending the following command
       to  LISTSERV@TAMVM1   via  mail   or  message:     SUB  CCMED-L
       Your_full_name.

       Owner:  Richard Holbert


       HAMLICEN@UIUCVMD

       The  list  HAMLICEN  has been  established  for  discussion  of
       Licensing matters of Ham Radio.   This is a splinter group from
       the  USENET newsgroup  "rec.ham-radio"  and  the digest  "info-
       hams@wsmr-simtel20.army.mil" to  separate the  high traffic  of
       the licensing discussion that have been taking place.   You may
       subscribe  to the  list  by sending  the  following command  to
       LISTSERV@UIUCVMD   via   mail  or   message:     SUB   HAMLICEN
       Your_full_name.

       Owner:  Philip Howard


       CUMREC-L@NDSUVM1

       The CUMREC-L  list is named after the annual conference.  It is
       designed to  be a forum for  the discussion of computer  use in
       college and university administration.   Topics include but are
       by no means be limited to:  Purchase of administrative software
       from vendors, general purpose software and hardware purchasing,
       the CUMREC conference  itself,  and just about  any subject for
       which a CUMREC paper could be written.

       You can subscribe to the CUMREC-L list by sending the following
       command to LISTSERV@NDSUVM1 via mail or message:   SUB CUMREC-L
       Your_full_name.

       Owner:  Joe Moore
1

                                                               Page 19


        *********
       *         *  Feedback
       *     *****
       *    ***  *  a Letters Column
       *   ***   *
       *  ***    *  "Letters!  Where are the letters?"
       *****     *
       *         *  Send your letters to BITLIB@YALEVM
        *********


       From:     Leonard D. Woren  
       Subject:  Computerization

       In the October NetMonth, T.  D.  Stephen compares BITNET access
       and  computer  use  with library  use.    It's  an  interesting
       analogy.   With both computer use and library use, once someone
       gets started,  they tend to find more uses than they originally
       planned.

       That's not the point of this letter, though.   Rather,  I would
       like to point out another trend in libraries:  computerization.
       At some leading universities (USC is one; UCLA is another), the
       library  is investing  heavily in  computer technology.    This
       takes two forms that I'm aware of:   (1)  online card catalogs,
       and (2)  online databases.   I believe that within a few years,
       people  who  are  put  off  by  computers  will  be  at  a  big
       disadvantage at the research libraries.

       A number of universities now  provide universal computer access
       to all  enrolled students.   Just as  each student may  use the
       research library,   each student automatically gets  a computer
       account.   USC is moving towards giving all registered students
       an e-mail account.  I believe that universities that don't have
       similar attitudes will,   in the near future,   have difficulty
       attracting  top  students,   and also  will  be  putting  their
       students at a disadvantage in this computer literate society.
1

                                                               Page 20


        *********
       *         *  NetMonth Policies
       *     *****
       *    ***  *  Everything you ever wanted to know...
       *   ***   *
       *  ***    *  ...but were afraid to ask.
       *****     *
       *         *  BITLIB@YALEVM
        *********


       NetMonth is a  network service publication distributed free  of
       charge to  students  and  professionals  in  BITNET  and  other
       networks. This magazine and its companion file, BITNET SERVERS,
       are the  work  of the  BITNET Services Library (BSL) staff  and
       contributors from around the network.

       BITNET SERVERS is BITNETs list of servers and services.  If you
       know of servers not listed in BITNET SERVERS, or if some listed
       are no longer available, please contact the NetMonth Editor.

       * Subscribing to NetMonth and BITNET SERVERS:

       Send  the  following  command  to  LISTSERV@MARIST  by  mail or
       messgage:

            SUBSCRIBE NETMONTH Your_full_name

       A subscriber  can delete  him/herself from  the mailing list by
       sending LISTSERV@MARIST the command:

            UNSUB NETMONTH

       Internet users may use these methods, but must address the mail
       to LISTSERV@MARIST.BITNET

       * Back issues:

       BITNET users  may get NetMonth back issues from the file server
       LISTSERV@CMUCCVMA.  For a list of  files,  send the  server the
       the command:

            INDEX NETMONTH

       * Letters to the Editor:  If  you  have  questions  or comments
       about BITNET or  NetMonth that you would like  to  see  printed
       here, mail  your letter  to BITLIB@YALEVM.  Make  sure that you
       specify in the "Subject:"  header or  somewhere  in  the letter
       that it is for the NetMonth letters column.
1

                                                               Page 21


       * Article Submissions:  The  only  requirements  for   NetMonth
       articles and columns are that they be informative, interesting,
       and concern some BITNET-related topic.  Send your articles  and
       to BITLIB@YALEVM.

       * Printing this file:  VM  users can print  this file  by using
       the "( CC" option of  the PRINT command.   VAX/VMS users should
       RECEIVE NetMonth  with a  format of  FORTRAN.  This  will allow
       page-breaks to be accepted by your printer.


            _
           __-
          __---    The
         __-----   BITNET
        __-------  Services
       ___________ Library                       "Because We're Here."

       ***************************************************************